Configure a Cache in the Downstream Consumer
Overview
When shared remotely, models and artifacts from the upstream owners' Istari installations are stored in a shared cache, for use by consuming downstream organization's Istari installation and users.
This section discusses configuration of a shared cache in order to share models with other organizations having Istari installations. NOTE, the models belong to the upstream owners, but the cache is configured to a tenant provisioned in the downstream consumer. Contol-plane to control-plane communications between Istari installations ensures appropriate security and access control in the downstream installation.
Since the information stored in the shared cache belongs to the organization of the upstream owners, we recommend that storage for the shared cache is provisioned by or owned by the upstream organization, to give that organization full control over their cached model data. The cache storage must be made available to the downstream consumer, and configured to a tenant in the downstream Istari installation, as described below.
The shared cache for upstream models is an object store, configured similarly to other Istari object stores as described in the Object Store Configuration section. This requires creating a tenant in the downstream organization that can be associated with the shared cache.
NOTE The required tenant in the downstream consumer's installation is needed in order to associate the shared cache with a tenant in the downstream environment.
Users in the downstream who are configured as remote owners of the sharing relationship will be able to synchronize models from the upstream owners to that downstream cache, and they will be granted ownership of models (and the associated upstream specific control tags) they synchronize to that cache. They can then share those models with others in the downstream organization as long as those users have been granted access to any upstream specific control tags that were associated with the models (by the upstream owners)
NOTE: As with all object stores associated with tenants in an Istari installation, all Istari users must have network access to the object store. The Istari system will ensure that appropriate access checks are enforced, and once a user's access is confirmed, data in the object store is made available to users via a presigned URL, so that no object store access credentials, such as an AWS Access Key ID or Secret Access Key, are exposed. This requires the Istari Registry Service Machine User identity has specific IAM permissions on the object store, as described in Istari Control Plane configuration documentation.
Shared Cache for Upstream Models vs. Istari Tenant Object Store(s)
Important differentiations for the object store(s) configured as a shared model cache include:
- Shared caches for Upstream Models should be provisioned and managed by the upstream Istari installation administrator, with appropriate permissions granted to the downstream Istari instance and downstream end users for read access to the shared cache.
- The shared cache may be configured to isolate storage containers on a 'per downstream' basis (e.g. one object store cache per downstream), or, a single shared cache may be configured to partition a single shared cache for use by multiple downstream organizations.
- The configuration of the shared cache is the responsibility of the upstream organization (the owner of the models to be shared), but, that shared cache is configured by the downstream organization and associated with a tenant in the Istari installation of the downstream consumer organization.
Shared Cache Configuration Options and Considerations
Note: Configuration choices and configuring access to the shared cache is the responsibility of the upstream organization, and these choices and configuration should be carefully considered and reviewed by network and security administrators prior to providing access to downstream organizations.
- Isolated Shared Caches (one per downstream organization involved in remote sharing)
- This option involves:
- Provisioning a separate cache object store for each downstream identity created for sharing
- Configuring access to that storage container so that the downstream Istari installation can write to the container, and downstream end users can read from the container
- Single Shared Cache for Upstream Models
- This option involves:
- Provisioning a single cache object store, for example, a single S3 bucket, to be used as a shared model cache by all downstream organizations
- Partitioning that cache object store to ensure each downstream organization has a separate, isolated folder or partition
- Configuring access to each object store partition so that the downstream Istari installation can write to the cache, and downstream end users can read from the cache, according to the different identities and access tokens (or 'PAT's) created for each sharing relationship.
- For the choice of using an S3 bucket, considerations could include the use of an S3 Access Point, or other IAM practices.